home *** CD-ROM | disk | FTP | other *** search
/ NetNews Offline 2 / NetNews Offline Volume 2.iso / news / comp / lang / c++-part2 / 11072 < prev    next >
Encoding:
Internet Message Format  |  1996-08-05  |  3.0 KB
  1. Path: admaix.sunydutchess.edu!ub!newserve!rebecca!rpi!not-for-mail
  2. From: ell@access4.digex.net (Ell)
  3. Newsgroups: comp.lang.c++.moderated,comp.object,comp.lang.c++
  4. Subject: Re: how many classes are too much? trying to follow Robert Martin's advice
  5. Date: 12 Mar 1996 13:53:55 -0000
  6. Organization: The Universe
  7. Sender: cppmods@netlab.cs.rpi.edu
  8. Approved: devitto@ferndown.ate.slb.com
  9. Message-ID: <4i3vlj$jcs@netlab.cs.rpi.edu>
  10. References: <4hn86s$im4@netlab.cs.rpi.edu> <4i1fim$bm5@netlab.cs.rpi.edu>
  11. NNTP-Posting-Host: netlab.cs.rpi.edu
  12. X-Original-Date: 12 Mar 1996 04:53:34 GMT
  13.  
  14. Robert C. Martin (rmartin@oma.com) wrote:
  15. :...
  16. : Class proliferation is a real problem.  And it is often novices that
  17. : have to face it first.  However, the problem is not simply the number
  18. : of classes that the novice produces, but the way in which the novice
  19. : produces them.  The novice will say:  "Oh gee, I could use a class for
  20. : this, and that, and the other, and -- wow -- I could use a class for
  21. : all kinds of things."  The result is a whole bunch of classes
  22. : conglomerated together into a morrass of "Gee Whizes". 
  23.  
  24. A few classes may or may not be what is required.  The real question is
  25. what does the vocabulary of the domain require?  Whether or not the
  26. required number of domain vocabulary classes results in a "morass" depends
  27. on how how well the developer uses an architecture to pull things
  28. together. 
  29.  
  30. : The experienced designer does not proliferate classes on a whim.  He
  31. : does *exactly* what you have done.  He starts with a few classes, and
  32. : then partition them according to their convenient abstractions.  
  33.  
  34. Should the developer partition according to "convenient abstractions"  for
  35. "a few classes", gained at one phase of project iteration, and
  36. incrementation or according to the overall architecture of the project
  37. based on analysis vocabulary? 
  38.  
  39. : each partitioning, the designer ensures that the resultant code is
  40. : simpler and more resilient to change. 
  41.  
  42. This is one goal of an iterative, incremental cycle.  There are others
  43. also, such as coming closer to the vocabulary of the domain and 
  44. fulfilling more project requirements.  Both of which may or may not 
  45. require more classes.
  46.  
  47. : You saw me do this in my book.  In almost every case I would start
  48. : with just a few simple core abstractions, and then I would hunt for
  49. : the underlying abstractions that would allow me to partition the
  50. : design to my advantage.
  51.  
  52. However the point of development is not only, or primarily gaining
  53. advantage in terms of a lesser number of classes and their resilience to
  54. change, in an effort to give the code designer an advantage.
  55.  
  56. Secondly here, how are underlying abstractions different from and more 
  57. important than domain vocabulary abstractions?
  58.  
  59. Elliott
  60.  
  61.       [ Articles to moderate: mailto:c++-submit@netlab.cs.rpi.edu ]
  62.       [  Read the C++ FAQ: http://www.connobj.com/cpp/cppfaq.htm  ]
  63.       [  Moderation policy: http://www.connobj.com/cpp/guide.htm  ]
  64.       [      Comments? mailto:c++-request@netlab.cs.rpi.edu       ]
  65.